feat: readyz: make the overall wait timeout configurable per template - #487

#714)

> Split out of #487, which bundled three unrelated changes.

## Summary

Envoy's end-to-end timeout on the workload route is hardcoded at `10s`
in
`buildRoutes`. An actor that legitimately holds a request open longer
gets cut
off: a harness relaying an LLM completion keeps the request open for the
whole
generation, and the client sees a **504 mid-turn**.

Adds `--route-timeout` on atenet-router, and pairs it with a route-level
`idle_timeout` so the ceiling is actually reachable. **The default is
10s, so
behavior is unchanged** unless an operator passes the flag.

## Why the route timeout alone was not enough

Raised in review by @LiorLieberman and @yan-vlasov, and they were right
— the
first version of this PR did not do what it claimed.

We never set `stream_idle_timeout` on the HTTP connection manager, so
Envoy
applies its default of **5 minutes**. Per the HCM proto, that default is
"overridable by the route-level `idle_timeout`", and when it fires "the
stream
is terminated with a 408 Request Timeout error code if no upstream
response
header has been received, otherwise a stream reset occurs."

That is exactly this PR's case. A turn relaying a non-streaming
completion sends
no bytes at all while the actor is thinking, and a request parked across
a
suspend/resume is idle by the same measure. Both are progressing; Envoy
cannot
tell. So `--route-timeout=30m` would still have been cut at 5 minutes
with a
408 — the knob would have looked like it worked and silently not.

`routeIdleTimeout()` therefore resolves the accompanying idle timeout as
`max(routeTimeout, 5m)`. Taking the larger keeps the operator's ceiling
honest
without ever making the idle timer *stricter* than it is today: below 5
minutes
the route timeout fires first regardless, so at the 10s default this is
a no-op.

Route-level rather than HCM-level, so it stays scoped to workload
traffic
instead of every stream through the router. It is derived rather than
exposed as
a second `--route-idle-timeout` flag so the two cannot drift apart, with
one
silently defeating the other — happy to make it explicit if reviewers
prefer.

For naming: what this PR sets is the route-level `timeout`, which bounds
upstream response time. Envoy's HCM `request_timeout` bounds how long
the
*request* takes to be received, which is not the limit in question here.

## Changes

`cmd/atenet/internal/router/` — adds `XdsServer.routeTimeout` with a
`SetRouteTimeout` setter and a `defaultRouteTimeout` const, wired from
`routerConfig.RouteTimeout` / `--route-timeout`. Same shape as the
adjacent
`SetExtProcMessageTimeout` and `SetExtProcMaxRequests`, and a flag on
the
existing config struct rather than an env read, matching the convention
the
parked-request work established. Wired in `startEnvoyDataplane`.

Adds `envoyDefaultStreamIdleTimeout` (5m) and `routeIdleTimeout()`,
applied as
the route's `IdleTimeout` in `buildRoutes`.

A non-positive value leaves the default in place, since Envoy reads a
zero route
timeout as *no timeout at all*.

The knob bounds the actor's own handling time only. The resume that may
precede
a request is covered by request parking and the ext_proc message
timeout, both
of which already derive from `--parked-request-budget`.

`manifests/ate-install/atenet-router.yaml` documents it as a
commented-out entry.

## Verification

- `go build ./...`, `go vet ./...`, `go test ./...` — all pass.
- `xds_test.go` reads the timeout back out of `buildRoutes`, where Envoy
  actually picks it up: default, setter override, and
  non-positive-keeps-default. The helper pins that route to
`OriginalDstClusterName` — a change that moved actor traffic onto some
other
route would otherwise leave the test passing while the timeout governed
a
  route nothing uses.
- Two added subtests cover the pairing:
`IdleTimeoutTracksLongerRouteTimeout`
  and `IdleTimeoutKeepsEnvoyDefaultWhenRouteTimeoutIsShorter`.
- **On a live GKE cluster**, read back out of Envoy's own
`/config_dump`. With
the new image and no flag, the workload route reports `timeout: 10s`, so
the
  default is genuinely unchanged. With `--route-timeout=5m` it reports
  `timeout: 300s`. Same binary, same manifest, only the flag differs.

Caveat on that measurement: it was taken before `ingress: route actor
ingress
through the atunnel mTLS server` landed, so the route it read was the
old
  `dynamic_forward_proxy` path to pod-IP:80. After rebasing, the timeout
attaches to the `actor_original_dst` route that replaced it — which is
now
pinned by the test above rather than left to inspection. The
`idle_timeout`
  pairing has test coverage only, not a live `/config_dump` read.
- **Regression, resume with parking on the path:** a conversation actor
that had
been suspended for 4 days was resumed by an ordinary request through the
  router — HTTP 200 in 3.74s, exactly one parked request,
`parking_wait_duration_seconds{outcome="served"} = 3.459s`, no shed and
no
  `budget_exhausted`.

## Follow-up

Per-ActorTemplate (or per-request) configurability, raised by @ronlv10:
agreed
it needs an API and is follow-up shaped rather than something to fold in
here.
The global flag remains useful as the cluster-wide ceiling.

## Relationship to #465

This is a stopgap for the connected-socket suspend/restore problem
tracked in
**#465 (suspend-safe actor networking)**. Once actor network traffic
survives
checkpoint/restore natively, much of the need to raise this ceiling
should go
away; this just makes the current behavior tunable in the meantime.


Fixes #<issue_number_goes_here>

> It's a good idea to open an issue first for discussion.

- [x] Tests pass
- [x] Appropriate changes to documentation are included in the PR

---------

Co-authored-by: Maya Wang <mymaya@google.com>